fix: bound JDTLS startup waits - #1790

Windows JVM CI did not stall in JDTLS on this PR.

The finalized log shows:

• test_find_symbol_references[java_model_refs] passed at 04:38:13 UTC
• all later Java basic and diagnostics tests passed, through 04:40:28 UTC
• output then stopped on TestKotlinDiagnostics::test_file_diagnostics[kotlin]
• GitHub cancelled the job at the 60-minute cap and killed an orphan java process

This is a separate Kotlin test-quarantine gap. Kotlin is intentionally disabled on CI in test/conftest.py, and TestKotlinLanguageServer carries the matching skipif, but TestKotlinDiagnostics does not. The four preceding Kotlin basic tests were skipped; the diagnostics test was then allowed to start the quarantined IntelliJ-based server and consumed the remainder of the job.

I am leaving that unrelated fix out of this focused JDTLS PR. The Java evidence supports the existing conclusion: this run does not identify an upstream JDTLS/m2e defect.

Closing — rationale below

Thanks for your PR, but the PR's own premise undermines it: two occurrences ever, both Windows CI, same test, 0/53 reproductions, no stalled phase identified, no upstream defect found. That's not a diagnosed problem — that's an undiagnosed CI flake, and this is 245 lines of production hardening against it.

Core objections:

1. No established problem. JDTLS stalling is not a pattern in real use. The likelier cause is environmental (runner starvation, shared workspace cache) — ci: exclude JDTLS workspaces from language-server cache #1788 addresses the latter directly. We should observe whether the flake survives ci: exclude JDTLS workspaces from language-server cache #1788 before touching the startup path.

2. Regression risk. Current behavior waits indefinitely and succeeds on slow-but-healthy startups (first-run Gradle/Maven import, cold indexes, weak machines). This PR kills JDTLS at ~590 s, converting those into hard failures. That's a worse trade than the twice-observed hang.

3. The tool-timeout capping is wrong on its own terms. The primary startup path runs as a background task with no timeout, and the motivating CI hangs happened in pytest fixtures where tool timeouts don't exist. Where startup does happen inside a tool call (LS auto-restart, terminated-LS retry), it begins mid-call, so capping against request_timeout — a per-request budget — guarantees no ordering. The Ubuntu "race" is a task-executor queuing race; the cap doesn't address it. It also hardcodes Serena's tool_timeout - 5 convention into solidlsp, which has no business knowing it, and adds a request_timeout property that's deliberately stale during startup.

4. Cost. A permanent config option, base-class API surface, and 218 lines of tests built on object.__new__ against private helpers — for a hypothesis.

Closing. If future evidence identifies an actual stall phase, a minimal bounded-startup change can be considered on that basis.